SPACE 2

home *** CD-ROM | disk | FTP | other *** search

/ SPACE 2 / SPACE - Library 2 - Volume 1.iso / program / 590 / doc / tricks.doc < prev

Wrap

Text File | 1992-01-06 | 29.9 KB | 958 lines

=============================================== @(#) OKAMI SHELL VERSION 1.4 - TIPS UND TRICKS =============================================== Stand: 26.12.91 BITTE ERST DIE DATEIEN README UND OKAMI.DOC LESEN! ---------------------------------------------------------------------------- INHALT Profile Aufruf von Programmen Benutzung der Shell von Diskette aus Beispiel-Shellscripts okback.sh e.sh showpic.sh startprg.sh Shell-Funktionen Die gemexec-Funktion Die screensave-Funktion Speichern und Restaurieren der Shell-Einstellungen MS-DOS-Gefühle C-Shell-Gefühle Andere Shells: Gulam, Master und bash Die Versionsnummer der Shell Diverses Trikolor-Bildschirm Aufruf vom Desktop Uneindeutige Kommandonamen Compiler-Aufruf Ändern von Dateinamen-Extendern Programmierung des UPN-Rechners ---------------------------------------------------------------------------- PROFILE Ich benutze das folgende Profile zum Konfigurieren der Shell. # Okami-Shell - System-Profile TERM=Atari Mega ST4 # Cursor etwas schneller blinkend cursor +bv 12 # Aktuelles Directory im Prompt anzeigen PS1=['$CWD'] ^^^$' ' # Pipes auf die Ramdisk PIPDIR=i:\ # Nach Ende der Shell CWD sichern... set +s # ...und den Cursor abschalten trap cursor -v # Directories trennen wie in Unix mit Slash set +b # anmelden als Applikation, sollte man immer machen gon # Word Wrap On echo ^033v # Bidschirm löschen durch viele Leerzeilen echo "^n^n^n^n^n^n^n^n^n^n^n^n^n^n^n^n^n^n^n^n^n^n^n" # Einschaltmeldung echo echo $TERM # Versionsnummer der Shell, des TOS und von MiNT ver -otM echo # Ausgabe des Datums des letzten Logins cat lastlog 2>NULL: echo # Ausgabe des freien Speichers echo Free RAM: `mem` Bytes echo # Ausgabe in invertierter Schrift echo ^033pType help for command survey.^033q echo # Datum speichern echo Last Login: `date` >lastlog # Letztes CWD zurückholen cd `cat wdir` Laufwerk I ist eine Ramdisk, die die Aufgabe hat, die Pipe-Operationen zu beschleunigen. Dadurch, daß die Pipe auf die Ramdisk gelegt wird (PIPDIR=i:\), erfolgen alle Pipe-Operationen ohne Plattenzugriff. Durch die Einstellung "set +s" wird die Shell veranlaßt, vor dem Pro- grammende das aktuelle Verzeichnis in die Datei $HOME\wdir zu schrei- ben. Das Profile benutzt diese Datei, um das aktuelle Verzeichnis wieder auf den alten Wert einzustellen. So ist man nach dem Start der Shell im- mer in dem Verzeichnis, in dem man war, als man die Shell zuletzt ver- lassen hatte. Durch die Einstellung "set +x" werden in einer Eingabe alle Slashes (/) in Backslashes (\) umgeformt, wodurch man die Möglichkeit hat, Dateina- men wie in Unix einzugeben, also shell/bin/sh.ttp anstatt shell\bin\sh.ttp. Natürlich erzeugt dann das Kommando echo 6/3=2 die Ausgabe 6\3=2 da alle Slashes umgeformt werden, aber das stört normalerweise nicht. (den UPN-Rechner stört es übrigens auch nicht, da er den Backslash als- Divisionszeichen versteht. Aus "upn 6 3 /" wird also "upn 6 3 \".) Außerdem kann man sich in Notfällen mit einfachen Anführungszeichen retten, echo '6/3=2' ergibt also immer 6/3=2 . ---------------------------------------------------------------------------- AUFRUF VON PROGRAMMEN (Der folgende Abschnitt ist im wesentlichen für Festplattenbenutzer von Interesse.) Viele Programme gehen davon aus, das sich gewisse Dateien wie z.B. RSCs im aktuellen Verzeichnis befinden. Um ein solches Kommando zu starten, muß man also mit cd in das jeweilige Verzeichnis wechseln, was unter Umständen einige Tipparbeit macht, vor allem bei einer Festplatte. Mit der Okami-Shell ist es möglich, Programme von überall, also von je- dem beliebigen aktuellen Verzeichnis aus zu starten. Es sei z.B. GEMTEST.PRG ein Programm, das im Verzeichnis D:\PROG\GEMTEST steht und eine RSC-Datei aus dem aktuellen Ver- zeichnis nachladen muß. Zum Start des Programms müßte man also eingeben cd d:\prog\gemtest gemtest Man kann allerdings auch so vorgehen: Man erzeugt sich eine Datei namens GEMTEST.SH im Verzeichnis $HOME\bin, die ungefähr so aussieht: A=`set -` set +x d:\prog\gemtest.prg set $A unset A Zuerst wird die aktuelle Einstellung der Flags in der Shellvariablen A ge- speichert, danach wird das Flag x aktiviert. Wenn dieses Flag aktiviert ist, führt die Shell vor dem Start eines Binärprogramms ein cd in das Di- rectory aus, in dem sich das Programm befindet. Nach dem Ende des Programms wird das ursprüngliche Directory wieder restauriert. Danach wird das Programm gestartet. Nach Programmende werden die Shell-Flags werden auf den gespeicher- ten Wert zurückgesetzt. Danach wird die lokal verwendete Shellvariable A freigegeben. Wenn das Flag -x immer gesetzt ist, kann man denselben Effekt errei- chen durch: hash gemtest d:/prg/gemtest/gemtest.prg Normalerweise ist das Flag x immer aktiviert. Programme, die sich in ei- nem der in der Shellvariablen PATH gespeicherten Directories befinden, werden also immer korrekt gestartet, indem man nur ihren Namen eingibt. ---------------------------------------------------------------------------- BENUTZUNG DER SHELL VON DISKETTE AUS Wenn möglich, sollte man die Shell auf einem schnellen Massespeicher wie Festplatte oder Ramdisk installieren. Wer die Shell hauptsächlich mit Disketten benutzt, ärgert sich vermutlich darüber, daß es ziemlich lange dauert, bis ein falsch eingetipptes Kommando als solches erkannt wird, da die Shell in allen möglichen Ordnern auf der Diskette nach einer passen- den Datei sucht. Mit den folgenden Einstellungen im Profile kann die An- zahl dieser Suchoperationen minimiert werden: PATH=.,$HOME\bin CDPATH=. Wenn man den Programm-Suchpfad auf das aktuelle Directory abkürzt (mit der Einstellung "PATH=."), werden noch weniger Suchoperationen durchgeführt, man kann dann allerdings die mitgelieferten externen Kom- mandos, die sich in dem Directory $HOME/bin befinden sollten, nicht mehr von überallher durch den einfachen Kommandonamen aufrufen, son- dern muß den ganzen Pfad angeben (z.B. nicht einfach "format", sondern "$HOME\bin\format.ttp"). ---------------------------------------------------------------------------- BEISPIEL-SHELLSCRIPTS 1) okback.sh Ich benutze das folgende Shellscript zum Sichern der Quelldateien der Shell auf Diskette. Es wird ein lzh-Archiv auf der Diskette angelegt, in das die seit dem letzten Backup geänderten Dateien hineingeschrieben werden. # Temporär-Directory DIR=M:/tmp/okbak # Liste der zu sichernden Dateien FILES=*.c *.h sh.prj alert stop 1 "Bitte die Okami-Backup-^|Diskette einlegen." ^ "Ok^|Abbruch" ERG if [ $ERG = 2 ] then exit fi # Temp-Dir anlegen und Archiv von der Diskette hineinkopieren mkdir -r $DIR/ cp -v a:/okbak.lzh $DIR # geänderte Dateien ins Archiv einfügen. # lharc ist ein externes Kommando. lharc a -by $DIR/okbak.lzh $FILES # Archiv wieder auf Diskette speichern cp -v $DIR/okbak.lzh a:/ # Log-Eintrag auf der Diskette erzeugen echo Okami-Source-Backup vom `date` >>a:/okbak.log # Temp-Directory entfernen rm -r $DIR unset DIR FILES ERG 2) e.sh Das Shellscript e.sh dient zum Aufruf des Editors. Das Editorprogramm befindet sich in der Datei $HOME\bin\editor.prg. Durch die Verwendung dieses Shellscripts ist es möglich, irgendwo im Dateisystem den Editor für irgendeine Datei aufzurufen. FILE=$* if [ -v FILE ] then FILE=$EFILE fi FILE=`fullname $FILE` $HOME\bin\editor.prg $FILE EFILE=$FILE unset FILE Der Name der zu editerenden Datei wird dem Script als Parameter über- geben. Die Zeile "FILE=`fullname $FILE`" erzeugt in der Variablen FILE den absoluten Dateinamen, der dem Editorprogramm als Parameter übergeben wird. Wenn dieses Script ohne Parameter aufgerufen wird, so wird der in der Shellvariablen EFILE gespeicherte Dateiname benutzt. In dieser Variablen wird nach jedem Editoraufruf der jeweilige Dateiname gespeichert, so daß man, wenn man dieselbe Datei mehrmals hintereinander editieren möchte, den Dateinamen nur einmal angeben muß: e datei.txt editieren von datei.txt e datei2.txt editieren von datei2.txt e ebenfalls datei2.txt Ggfs. muß man dieses Script noch erweitern, um dem Editor mehrere Pa- rameter zu übergeben (für den Micro-Emacs z.B. den Namen der Konfi- gurationsdatei o.ä.). 3) showpic.sh Dieses Script zeigt, wie man die Shell programmieren kann. Es dient da- zu, Bilddateien, die im Bitmap-Screenformat abgespeichert wurden (Datei- länge >32000 Bytes), zu laden und anzuzeigen. Es gehört zum Lieferum- fang der Shell, die Bedienungsanleitung befindet sich in commands.doc. 4) startprg.sh Die Idee zu diesem Shellscript stammt von Thomas Behrens aus Eschwei- ler und lautet, ein Programm in einer Fileselectbox auszuwählen und dann zu starten. Dazu genügt eigentlich die folgende Zeile: fsel | xargs {} oder noch einfacher `fsel` , wenn man aber den Abbruch-Button der Box abtesten und dem Pro- gramm eine Parameterzeile übergeben will, sollte man folgendes Script benutzen: FILE=`fsel *.* "" KEY "Welches Programm ausführen?"` if [ $KEY = 1 ] then echo "Bitte Kommandozeile eingeben:" read CMD $FILE $CMD fi unset FILE KEY CMD Beide Lösungen funktionieren übrigens sowohl mit Binärprogrammen als auch mit Shellscripts. --------------------------------------------------------------------------- SHELL-FUNKTIONEN Natürlich sollte man alle häufig gebrauchten Shellscripts resident halten, und zwar als Shellfunktionen. Es ist möglich, ein Shellscript so zu schrei- ben, daß es sich beim ersten Aufruf selber als Funktion installiert; bei al- len weiteren Aufrufen wird dann die Funktion benutzt. Sei z.B. folgendes Shellscript in der Datei hallo.sh, also unter dem Na- men hallo aufzurufen: echo Hallo Anwender! echo Der freie Speicherplatz beträgt `mem` Bytes. echo Auf Platte C: sind `df -f c:` Bytes frei. Setzt man nun die Zeilen hallo() { an den Beginn und die Zeilen } hallo an das Ende dieses Scripts, also so: hallo() { echo Hallo Anwender! echo Der freie Speicherplatz beträgt `mem` Bytes. echo Auf Platte C: sind `df -f c:` Bytes frei. } hallo , so wird beim Start des Scripts die Shellfunktion hallo installiert, und bei jedem weiteren Aufruf von hallo wird nicht das Script, sondern die Funk- tion aufgerufen. Mit dem Kommando unset hallo kann man die Funktion wieder aus dem Speicher entfernen. Die Shellfunktionen machen übrigens eine alias-Funktion völlig überflüssig, da sie auch benutzt werden können, um interne Kommandos umzudefinie- ren: Wer anstelle von ls lieber ls -C hat, gibt einfach ein ls() { !ls -C $* } Das Ausrufezeichen verhindert, daß sich die ls-Funktion selber aufruft. !ls ist immer das interne Kommando ls. Wer irgendwann das normale ls be- nutzen will, kann das tun, indem er es als !ls aufruft. Ebenso helfen Shellfunktionen, Tippfehler zu vermeiden; wer ständig dor oder dior statt dir tippt, versuche dior() { dir $* } (Wer sich wundert, daß die Okami-Shell trotzdem ein alias-Kommando hat: das dient nur dazu, das Anlegen dieser Mini-Funktionen einfacher zu gestalten und um Shellscripts anderer Shells ausführen zu können. Man kann also ebenso schreiben: alias ls !ls -C und alias dior dir .) Mein Unix-Tippfehler-Script enthält mehrere Dutzend Schreibweisen der häufig benutzten Kommandos wie dir, grep und der Make-Aufrufe xmake, qmake und remake. Besondere Funktionen haben die vordefinierten (aber vom Anwender voll- ständig umdefinierbaren) Shellfunktionen gemexec und screensave, die in den folgenden Abschnitten beschrieben werden. --------------------------------------------------------------------------- DIE GEMEXEC-FUNKTION Mit der kann man wirklich einiges machen, denn sie gibt dem Anwender die Möglichkeit, das Verhalten der Shell beim Start von GEM-Programmen frei zu programmieren. Dabei stehen ihm alle die nicht zu unterschätzen- den Funktionen der Shell zur Verfügung. Die folgende gemexec-Funktion kann benutzt werden, um nach dem Ende eines GEM-Programms den Bildschirm wieder so herzustellen, wie er vor dem Aufruf war. Dazu werden die internen Kommandos getscr und putscr sowie die VT52- Sequenzen zum Speichern und Wiederherstellen der Cursorposition be- nutzt. Dabei werden allerdings 32000 Bytes zum Speichern des Bildschir- minhaltes belegt. Aus diesem Grund speichert die Funktion den Bildschirm nur dann, wenn die Shellvariable SAVESCR gesetzt ist. Man kann das Speichern also mit SAVESCR=1 ein- und mit SAVESCR= wieder ausschalten. gemexec() { _=$0 if [ +v SAVESCR ] then # Cursorposition speichern echo ^033j^c # Bildschirm speichern getscr fi # Bildschirm grau scr -g # Cursor unsichtbar cursor -v # das Gem-Programm ausführen exec -g $_ if [ +v SAVESCR ] then # Bildschirm wiederherstellen putscr # Speicher freigeben putscr -f # Cursorposition wiederherstellen echo ^033k^c # Cursor wieder sichtbar cursor +v else cls fi unset _ } Das folgende Beispiel zeigt, wie man das "Applikation anmelden" des Desktops auf diese Weise simulieren kann. Es macht alle Dateien mit Ex- tender .gfa und .c ausführbar. Beim Ausführen einer .gfa-Datei wird der GFA-Basic-Interpreter, beim Ausführen einer .c-Datei der C-Compiler auf- gerufen. Alle anderen Programme werden wie üblich ausgeführt. Wichtig dabei ist, daß die Extender .gfa und .c sowohl in XEXT als auch in GEXT aufgeführt werden. XEXT=$XEXT,.gfa,.c GEXT=$GEXT,.gfa,.c gemexec() { _=$0 $* # Extender ermitteln, Flag setzen F=0 E=`extname $_` # GFA-Basic? if [ $E = .gfa ] then F=1 exec -g d:/gfabasic/gfabasic.prg $_ fi # C-Source? if [ $E = .c ] then F=1 exec -g d:/compiler/cc.ttp $_ fi # Weder-noch, also normal ausführen if [ $F = 0 ] then # wie das Default-gemexec cls cursor -v exec -g $_ cls fi # Variablen freigeben unset E F _ } Die Benutzung des Flags $F entscheidet darüber, ob das Programm am Ende doch noch mit exec -g aufgerufen wird. --------------------------------------------------------------------------- DIE SCREENSAVE-FUNKTION Wenn in der Eingabe Control-P gedrückt wird, ruft die Shell die Shell- funktion screensave auf. In der Voreinstellung wird dadurch die normale Drucker-Hardcopy ausgelöst (was sinnvoll ist, wenn die Tastenkombination Alt-Help von einem residenten Programm okkupiert ist), aber durch Än- dern der screensave-Funktion kann der Anwender jede beliebige Operation durch Ctrl-P auslösen lassen. Die folgenden drei screensave-Funktionen dienen dazu, die Hardcopy ähnlich dem Snapshot-Programm in eine Datei umzuleiten. Die erste Version fragt den Anwender mit einer Fileselect-Box nach dem Dateinamen. Diese Funktion geht davon aus, daß gon aktiviert ist. Alle Versionen stellen während des Speicherns den Cursor auf nichtblin- kend und schalten ihn, wenn die Shell wieder zur Eingabe bereit ist, wie- der auf blinkend zurück. Wer das nicht will, läßt die cursor-Aufrufe weg. screensave() { # Cursor nicht blinkend cursor -b # Bildschirm sichern getscr # nach einem Dateinamen fragen fsel *.pic "" KEY "Dateiname für Hardcopy?" | read FILE # Abbruch geklickt? if [ $KEY = 1 ] then # nein, in die Datei speichern putscr -s $FILE fi # Speicher und Variablen freigeben putscr -f unset KEY FILE # Cursor wieder blinkend cursor +b } Die zweite Version verhält sich eher wie das Snapshot-Programm. Sie baut selber einen Dateinamen zusammen. Der Dateiname ist "screen.", der Extender eine laufende Nummer. Der Zähler befindet sich in der Shellvariablen _SCRCOUNT, aufwärtsgezählt wird mit Hilfe des UPN-Rech- ners. screensave() { cursor -b getscr if [ -v _SCRCOUNT ] then # Wenn es die Zählvariable noch nicht gibt, # bei 0 anfangen _SCRCOUNT=0 else # ansonsten 1 addieren. upn %ld $_SCRCOUNT ++ | read _SCRCOUNT # Das Ergebnis lassen wir nicht auf dem Stack # rumliegen... upn pop fi # wie oben. putscr -s screen.$_SCRCOUNT putscr -f cursor +b unset FILE } Die dritte Version fragt den Anwender, ob er die Hardcopy in eine Datei oder auf den Drucker haben möchte. Es benutzt dazu eine Alert-Box, funktioniert also nur, wenn gon aktiv ist. (Was aber kein Hindernis ist, da gon normalerweise im Profile steht und somit im normalen Betrieb immer aktiv ist. Nur in dem Profile für die Auto-Ordner-Shell sollte kein gon stehen.) screensave() { # Zuerst den Bildschirmspeicher sichern cursor -b getscr # Dann den Anwender fragen alert ques 1 "Bildschirm speichern nach..." ^ "Drucker^|Datei" A read A if [ $A = 1 ] then # Druckerausgabe, dazu den Bildschirm wieder so # herrichten, wie er vor dem echo war putscr hardcopy else # Datei .................... (wie eins der beiden obigen Beispiele) fi # Speicher freigeben putscr -f unset A cursor +b } Man kann das natürlich beliebig weit treiben und ein komplettes Menü- programm schreiben, daß mit Ctrl-P aufgerufen wird. --------------------------------------------------------------------------- SPEICHERN UND RESTAURIEREN DER SHELL-EINSTELLUNGEN Die Okami-Shell bietet die Möglichkeit, einen großen Teil ihrer Einstellun- gen bei Programmende abzuspeichern und beim nächsten Programmstart wiederherzustellen. Die folgenden Kommandos sollte man in sein Profile schreiben, um die einzelnen Funktionen zu übernehmen. 1. Das aktuelle Directory: set +s 2. Die history-Liste: trap +history ^>$HOME/hist.sav history -l <$HOME/hist.sav 3. Die Shellvariablen: trap +vars -x ^>$HOME/vars.sav trap +export ^>>$HOME/vars.sav trap +readonly ^>>$HOME/vars.sav . $HOME/vars.sav 4. Die Shellfunktionen: trap +fcts -l ^>$HOME/fcts.sav . fcts.sav 5. Die set-Einstellungen: trap +set - ^>$HOME/set.sav xargs set <$HOME/set.sav 6. Die Blinkrate des Cursors: trap +cursor ^>$HOME/cursor.sav xargs cursor <$HOME/cursor.sav 7. Die Tastatureinstellung: trap +keyb - ^>$HOME/keyb.sav xargs keyb <$HOME/keyb.sav 8. Die umdefinierten Funktionstasten: trap +keydef list ^>$HOME/keydef.sav . $HOME/keydef.sav 9. Das Clipboard-Directory: trap +echo 'clipb $CLIPDIR' ^>$HOME/clipb.sav . $HOME/clipb.sav Vorher sollte allerdins "gon" im Profile stehen. 10. Die Laufwerksbezeichnungen: trap +drive ^>$HOME/drive.sav xargs drive <$HOME/drive.sav 11. Die Hashtabelle: trap +hash * ^>$HOME/hash.sav . $HOME/hash.sav 12. Den OverScan-Modus: trap +echo overscan ^`overscan^` ^>$HOME/overscan.sav . $HOME/overscan.sav --------------------------------------------------------------------------- MS-DOS-GEFÜHLE Die Unverbesserlichen, die sich statt wie in Unix lieber wie in MS-DOS fühlen wollen und das aktuelle Laufwerk nicht mit cd a: , sondern einfach mit a: einstellen wollen, können sich mit entsprechenden Shellfunktionen helfen. Setzt man sich folgende Zeilen für jedes angemeldete Laufwert ins Pro- file: a:() { cd a: } A:() { cd a:\ } dann kann man durch Eingabe von a: das aktuelle Laufwerk a: einstellen und durch Eingabe von A: in Mupfel-Manier ins Rootdirectory von a: wechseln. Eine Liste der angemeldeten Laufwerke erhält man bekanntlich mit df -m . Natürlich kann man sich diese Funktionen auch in eine eigene Datei, z.B. msdos.sh, schreiben und diese dann im Profile mit . msdos.sh aufrufen. Unixfans erstellen außerdem eine Datei namens killmsdos.sh, in der sie mit den Zeilen unset a: A: usw. (für jedes vorhandene Laufwerk) die MS-DOS-Funktionen wieder lö- schen. --------------------------------------------------------------------------- C-SHELL-GEFÜHLE Wer sich lieber wie in der C-Shell (/bin/csh) fühlt als wie in der Bourne-Shell, kann sich auch mit Shellfunktionen helfen. In der C-Shell werden Variablen mit dem set-Kommando gesetzt: set() { VAR=$1 VAL=$2 $3 $4 $5 $6 $7 $8 $9 $VAR=$VAL unset VAR VAL } Environmentvariablen setzt man man mit setenv. setenv() { VAR=$1 VAL=$2 $3 $4 $5 $6 $7 $8 $9 $VAR=$VAL export $VAL unset VAR VAL } --------------------------------------------------------------------------- ANDERE SHELLS: GULAM, MASTER UND BASH In manchen Punkten ist die Gulam-Shell unschlagbar, z.B. was den einge- bauten Editor angeht, in anderen Beziehungen hat Okami die Nase vorn (z.B. bei den Möglichkeiten von chmod und Pipes.) Man kann die Gulam- Shell von der Okami-Shell aus aufrufen, dabei werden alle exportierten Shellvariablen übergeben und können unter Gulam mit setenv angesehen werden (anders als Okami unterscheidet Gulam zwischen Environment- und Shell-Variablen). Fast dasselbe gilt für dir kommerzielle Master-Shell, von der mir leider nur das Referenzhandbuch zur Verfügung stand. Obwohl Master eine Rei- he von Fähigkeiten hat, vor denen Okami sich respektvoll verbeugen muß, z.B. Unix-Filenamen und Regular Expressions bis auf TOS-Ebene, Links und Locks usw., ist Master doch in nicht allen Punkten voraus. Die Shell- funktionen von Okami sind dem alias-System sicherlich in ihrer Flexibilität weit überlegen (programmieren Sie mal while und if in ein alias), und Okami hat eine ganze Reihe von internen Kommandos, die die Program- mierung vereinfachen, z.B. basename, test, getscr/putscr usw., die Master vermissen läßt. Ein gewaltiges Plus für Okami ist natürlich der Preis: wer direkt bei mir bestellt, zahlt nicht mehr als zwei DM für Porto. Die zu MiNT gehörende bash, die ebenso wie Okami an der Bourne-Shell orientiert ist, ist ebenfalls eine großartige Shell, hat aber den Nachteil, praktisch keine internen Kommandos zu haben. Man muß also alle Kom- mandos, auch ls, cp, rm usw., als separate Programmdateien auf der Platte haben. Obwohl das sehr Unix-like ist, bedeutet es einen enormen Platz- und Zeitbedarf; m.E. ist der Atari für so etwas nicht ganz der richtige Rechner. Durch ihre Möglichkeit, in der Kommandozeile nach "-c" Kommandos zur Asführung übergeben zu bekommen, kann die Okami-Shell so installiert werden, daß sie für die wesentlichen Kommandos von der bash aufgeru- fen wird. ---------------------------------------------------------------------------- DIE VERSIONSNUMMER DER SHELL "Was heißt Manta GTE? - GETUNED EY!!!!!!" (unbekannter Manta-Witz-Erfinder) Damit keine ähnlichen Mutmaßungen über die Bedeutung der Versions- nummer der Okami-Shell aufkommen, hier die genaue Beschreibung, was selbige uns zu sagen hat. Die Versionsnummer, die in der Shell-Variablen $VERSION gespeichert ist und von dem ver-Kommando ausgegeben wird, gibt ziemlich genaue Aus- kunft über die vorliegende Version der Shell und ist folgendermaßen auf- gebaut: z.B. "1.3d+ X" 1 : die Hauptnummer (eine Zahl, gefolgt von einem Punkt) diese Nummer ändert sich nur unter besonderen Umständen, z.B. Portierungen auf andere Rechner oder größeren Umstellungen der Programmstruktur, Bedienung usw. Versionen mit unter- schiedlicher Hauptnummer sind nicht unbedingt kompatibel zu- einander. 3 : die Versionsnummer (eine Zahl) kennzeichnet die laufende Nummer der Shell und ändert sich mit den vollständigen (d.h. garantiert vollständig getesteten und dokumentierten) Versionen, die von Zeit zu Zeit veröffentlicht werden, wenn mir mal eine Weile nichts neues einfällt (also nicht allzu häufig). Diese Ver- sionen werden über Pd-Versandstellen vertrieben. Alle anderen Angaben treten optional auf: d : die Zwischen-Release-Nummer (ein Kleinbuchstabe) kennzeich- net Releases, die zwischen den o.a. Versionen herauskommen. Wer seine Shell direkt bei mir bestellt, bekommt mit großer Wahrscheinlichkeit eine solche Zwischenversion. Sie sind im großen und ganzen fehlerfrei und dokumentiert, obwohl das hier nicht so sicher ist wie bei den Hauptversionen (die keine Zwischen-Release-Nummern haben). + : die Test-Kennung, kennzeichnet Arbeitsversionen, die normaler- weise nicht veröffentlicht werden. Diese Versionen enthalten möglicherweise noch Fehler. X : die Erweiterungsspezifikation (ein oder mehrere Großbuchsta- ben) kennzeichnet erweiterte, verkürzte oder konfektionierte Versionen. Folgende Erweiterungsspezifikationen können auftre- ten: C es handelt sich um die "CLI-Only"-Version der Shell, die nur die wichtigsten Kommandos enthält. F die Version enthält eine höhere Anzahl von Shellfunktio- nen. V die Version enthält eine höhere Anzahl von Shellvariab- len. L die Version enthält eine höhere Anzahl von verschachtel- baren while-Ebenen. X die Version enthält sonstige Erweiterungen der Kapazität. R die Version ist restriktiv, d.h. sie enthält wesentlich we- niger interne Kommandos als die regulären Versionen. P bei Programmstart wird das Profile immer geladen, außer es wird der Parameter "-" übergeben (die regulären Ver- sionen verhalten sich umgekehrt). K die Version ist auf die Wünsche eines bestimmten An- wenders konfektioniert. Die zeitliche Reihenfolge der Versionen lautet also: 1.3 Hauptrelease 1.3+ Arbeitsversion 1.3a Zwischenrelease 1.3a+ Arbeitsversion 1.3b Zwischenrelease 1.3b+ Arbeitsversion .... 1.4 Hauptrelease 1.4+ Arbeitsversion usw. Eine genauere Analyse der Shell (Anzahl der möglichen Variablen, Shell- funktionen und geschachtelten whiles, maximale Zeilenanzahl des sort- Kommandos,Länge des History-Puffers, Größe des UPN-Stacks usw.) kann mit dem Kommando "ver -l" erzeugt werden. ---------------------------------------------------------------------------- DIVERSES Trikolor-Bildschirm: Durch Verwendung des Kommandos scr -b ; cursor +bv 1 auf einem Monochrom-Bildschirm blinkt der Cursor so schnell, daß er wie eine dritte Farbe auf dem Bildschirm wirkt. Dieser Effekt ist jedoch nur bei dunklem Hintergrund (scr -b) deutlich sichtbar. ~~~~~~~~~~~~~~~~~~~ Aufruf vom Desktop: Wenn man sh.ttp vom Desktop aufruft und eine Kommandozeile eingibt, die von der Shell ausgeführt werden soll, so erscheint nach der Ausfüh- rung dieser Kommandos wieder das Desktop, ohne daß der Anwender Zeit hat, eventuelle Ausgaben zu lesen. Um das zu verhindern, kann das read-Kommdando benutzt werden. Um z.B. für alle angemeldeten Laufwerke die Platzstatistik (mit dem Kom- mando df) zu erhalten, doppelklickt man auf sh.ttp und gibt folgende Kommandozeile ein: -c df ; read oder -c df ; echo Taste: ; read (Die Leerzeichen um die Strichpunkte sind nicht unbedingt notwendig). Nach der Ausführung von df wartet die Shell auf eine Eingabe (die durch Druck auf RETURN beendet sein muß). Im zweiten Beispiel wird außer- dem noch der Text "Taste:" ausgegeben. ~~~~~~~~~~~~~~~~~~~~~~~~~~ Uneindeutige Kommandonamen: Wenn ein Programm denselben Namen wie ein internes Shellkommando hat, dann kann dieses Programm nicht einfach mit Namen aufgerufen werden. Hat man z.B. ein Script namens test.sh, dann wird durch Eingabe von "test" nicht das Script, sondern das interne Kommando "test" aufge- rufen. Um das zu verhindern, gibt man den Kommandonamen in Groß- buchstaben ein, also "TEST" oder "Test", dann wird das externe Komman- do aufgerufen. Das liegt daran, daß Groß-Kleinschreibung bei internen Kommandos von Bedeutung ist, bei Dateinamen und damit bei externen Kommandos aber nicht. ~~~~~~~~~~~~~~~~ Compiler-Aufruf: Folgende Zeilen habe ich im Aufrufshellscript für den Compiler: D=`date` echo $D echo "#define _CMP_DAT" ^"$D^" >$INC/cmpdat.h Dies erzeugt bei jedem Compileraufruf eine Headerdatei namens cmpdat.h (die Environmentvariable INC speichert den Pfad der Headerdateien), in der ein Makro namens _CMP_DAT definiert wird, das das aktuelle Datum enthält, z.B. #define _CMP_DAT "03.07.1991 19:54:42" Diese Datei in die C-Quellen eingebunden, und man hat in jedem Pro- gramm das individuelle Datum der Erstellung. Wer einen Ansi-C-Compiler hat, ist darauf natürlich nicht angewiesen und kann stattdessen folgendes benutzen: #define _CMP_DAT __DATE__ " " __TIME ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Ändern von Dateinamen-Extendern: Die Kommandos basename, dirname und extname kann man benutzen, um den Extender einer Datei zu ändern, z.B. um zu einer C-Quelldatei den Namen der zugehörigen Objektdatei zu ermitteln. Man kann dieses Kommando zusammen mit "dirname" benutzen, um z.B. zu dem Namen einer C-Quelldatei den Namen der zugehörigen Objektda- tei zu ermitteln. echo Bitte einen C-Quelldateinamen eingeben: read FILE EXT=`extname $FILE` if [ $EXT != .c ] then echo Das ist keine C-Quelldatei! else DIR=`dirname $FILE` FILE=`basename $FILE .c` echo Die Objektdatei ist $DIR/$FILE.o fi unset FILE DIR Ergibt: Bitte einen C-Quelldateinamen eingeben: e:/okami/cmds4.c Die Objektdatei ist e:/okami/cmds4.o ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Programmierung des UPN-Rechners: Der UPN-Rechner ist nicht wirklich programmierbar, aber es ist möglich, häufig benutzte Sequenzen von Kommandos in Shellvariablen abzulegen und diese dann mit dem UPN-Rechner zu benutzen. Die folgende Zeile speichert in der Variablen BKOEFF ein Programm zum Berechnen des Binominalkoeffizienten. BKOEFF="2 sto 1 sto 1 rcl fact 2 rcl fact 1 rcl 2 rcl - fact * /" Um z.B. 5 über 3 zu berechnen, gibt man ein: upn 5 3 $BKOEFF Um die Summe aller Zahlen von 1 bis zu einem x zu berechnen, kann man folgendes Programm benutzen: SUM="dup sqr + 2 /" Dann berechnet "upn 5 $SUM" die Summe der Zahlen von 1 bis 5. Dies funktioniert auch mit dem calc-Shellscript.